ELB + CloudWatchアラームを使ったEC2サービス監視プラクティス

はじめに

皆さん、CloudWatchは活用されていますか？CloudWatchはとても便利なサービスで、特別な監視システムを入れなくとも、AWSの標準的な仕組みとしてAWSリソースのモニタリングを行ってくれます。またアラームの設定も行えますので、例えば「EC2のCPU使用率が閾値を超えた場合にメール通知する」といった通知の仕組みもAWSだけで簡単に設定できます。

このCloudWatchアラームの仕組みを使えば、ELBとEC2による負荷分散システムにおいて、EC2のサービス監視が行えます。具体的には、ELBの分散対象であるEC2でHTTPなどの分散対象サービスが正常に動作していない場合に、アラームを発報しメール通知などを行うことで、早期にシステム障害を検知することが出来ます。

この記事では、ELB分散対象のEC2で発生したサービス障害を検知するプラクティスをご紹介します。

EC2の状態毎のCloudWatchの値を確認する

まず、EC2のサービス状態によってCloudWatchの値がどう変わるのかを確認しましょう。CloudWatchの値としては以下の2つの状態を確認します。

HealthyHostCount	ELBから見た正常なEC2インスタンス数の数
UnHealthyHostCount	ELBから見た異常なEC2インスタンス数の数

確認する環境では、以下のようにELBの分散対象としてEC2を1台だけ配置しています。EC2ではApacheを動作させ、HTTPをロードバランシング対象としています。

通常時

ELBから見てEC2が正常にサービス提供されている場合(つまりHealthCheckが成功している場合)、ELBではEC2を[InService]というステータスで認識します。

この時、Healthy Hostsは1に、Unhealth Hostsは0になります。わかりやすいですね。

 EC2のサービスが停止した場合

EC2で動作している、ロードバランシング対象のサービスが停止した場合(今回だとEC2上でservice httpd stopした場合)、HealthCheckが失敗しますので、ELBではEC2が[OutOfService]というステータスになります。

この時、Healthy Hostsは0に、Unhealth Hostsは1になります。

EC2自体が停止した場合

EC2自体が停止した場合も、サービスが停止した状態と同様にHealthCheckが失敗しますので、ELBではEC2が[OutOfService]というステータスになります。

この時、Healthy Hostsは0に、Unhealth Hostsは1に...なりません。EC2自体が停止している場合にはデータ自体が取れず、Healthy HostsもUnhealthy HostもNo Dataとなります。

アラームをどう設定すべきか

つまり、「Healthy Hostsが1以下」または「Unhealthy Hostsが0以上」という条件では、EC2自体が停止してしまった場合はCloudWatchアラームは発報しない、ということになります。

「ロードバランシング対象サービスに異常がある場合」にも「EC2自体が停止した場合」にもどちらでもCloudWatchアラームを発報させるには、CloudWatchアラームのActionsの設定で、

• ステータスがALARM(閾値を上回った場合、以下の設定ではHealthyHostsが1以下になった場合)
• ステータスがINSUFFICIENT(データが不足している場合)

のどちらもアクション対象として設定してあげる必要があります。

これでELB分散対象のサービスが正常に提供できなくなった場合にはすぐに検知することが出来ます！

さいごに

CloudWatchアラームの詳細な設定は、AWS管理コンソールの各AWSリソースの画面では無くCloudWatchの画面から行う必要があるため、使い慣れていないとなかなか気づきません。ぜひCloudWatchの画面で色々な設定を試して頂き、運用の効率化を図って頂ければと思います。